Method, system and software for state signing of internet resources

ABSTRACT

A method, system, and software for state signing of Internet resources is presented in which web pages and other Internet resources are signed after the insertion of metadata indicating intended and authorized uses. In one embodiment, the signing is accomplished through use of a cryptographic signature added to any data item passed to a client that is likely to be passed back to the server later, such as a cookie, URL, or data integrity item. Enabling/disabling of state signing for various data items can be controlled through policies tied to URL prefixes.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This patent application claims priority to, and incorporates byreference in its entirety, U.S. Provisional Patent Application No.60/473,931, entitled “Method, System and Software for State Signing ofInternet Resources” and filed May 28, 2003. This patent applicationincorporates by reference in its entirety each of the followingco-pending U.S. patent applications: 1) “Method and System forIdentifying Bidirectional Packet Flow” filed on May 28, 2004; 2) “PolicyBased Network Address Translation” filed on May 28, 2004; and 3)“Multilayer Access Control Security System” filed on May 28, 2004.

BACKGROUND

[0002] Internet resources, and in particular web applications, are oftendeveloped with fields which can be altered or abused by those accessinga resource. However, the resource developer may assume that the resourceis unalterable or secret (unpredictable or incapable of being guessed).These fields can include, for example, cookies, hidden inputs on formsand Uniform Resource Locators (“URLs”).

[0003] Many Internet applications, such as web sites and other corporateresources, can be infiltrated using only a text editor. ExemplaryInternet attacks that exploit misplaced trust in client data includecookie tampering, parameter tampering, hidden field manipulation,stealth commanding, forceful browsing, Structured Query Language (SQL)injection, overflow attacks, and others application level attacks.

[0004] Current solutions to prevent field tampering exist in the form ofsoftware that monitors all traffic going to and from an Internetapplication. Based on a comprehensive rule set that identifies normalapplication use, existing products infer session information and analyzeall Hypertext Transfer Protocol (“HTTP”) packets by putting all packetsthrough a rule engine that represents the web application state machine.A rule set maintained by the rule engine mirrors the complexity of theweb application and is derived using either explicit configuration or a“learning mode” which attempts to generate the state machine byobserving presumably “correct” behavior.

[0005] Existing solutions have significant drawbacks, however, in termsof configuration complexity, scalability, performance and accuracy.Every web site or web application has a different set of rules that mustbe learned or configured into the system. Changes to the web site maycause the rule set to be rendered invalid and can requirereconfiguration or relearning of a new rule set. The complexity of therules also requires significant CPU capacity and memory to process eachweb transaction.

[0006] For the foregoing reasons, a need exists for a method, system andsoftware for state signing to determine whether fields in a web page orother Internet resource have been altered or abused.

SUMMARY

[0007] Before the present methods and systems are described, it is to beunderstood that this invention is not limited to the particularmethodologies and systems described, as these may vary. It is also to beunderstood that the terminology used in the description is for thepurpose of describing the particular versions or embodiments only, andis not intended to limit the scope of the present invention which willbe limited only by the appended claims.

[0008] It must also be noted that as used herein and in the appendedclaims, the singular forms “a,” “an,” and “the” include pluralreferences unless the context clearly dictates otherwise. Thus, forexample, reference to a “server” is a reference to one or more serversand equivalents thereof known to those skilled in the art, and so forth.Unless defined otherwise, all technical and scientific terms used hereinhave the same meanings as commonly understood by one of ordinary skillin the art. Although any methods, materials, and devices similar orequivalent to those described herein can be used in the practice ortesting of embodiments of the present invention, the preferred methods,materials, and devices are now described. All publications mentionedherein are incorporated by reference. Nothing herein is to be construedas an admission that the invention is not entitled to antedate suchdisclosure by virtue of prior invention.

[0009] In an embodiment, a state signing procedure is used to encode the“state” of the web application into the page delivered to the client. Inan embodiment, no server side configuration is required. In an alternateembodiment, the only configuration needed on the device (hardware,software, or combination thereof) implementing the state signingfunction is to enable or disable the state signing for a particular website. Because a server requires only minimal configuration, web sitesmay incorporate the state signing system without otherwise modifying theweb site or installing software containing complex rules. In anembodiment, the state signing procedure is implemented when the webserver transmits the page (either directly or via a web proxy). Changesin the web application do not affect the state signing procedure becausethe web page is not signed until it is transmitted.

[0010] In an embodiment, state signing is performed by incorporatingsecurity metadata in transmissions from a network application server toa client. The security metadata may contain descriptions describingintended network application semantics. The security metadata mayindicate how a URL, cookie, data integrity item (used in form fieldverification) or other network application element is to be used. Atsome point subsequent to the receipt of the requested networkapplication element, the client transmits a request back to the server.The server may analyze the transmission from the client to determine ifit conforms to the intended network application semantics and is safe touse.

[0011] Intended network application semantics are descriptions of waysin which information can be returned to the server from the client in aform that does not put the server at risk. Examples of intended networkapplication semantics include: returning cookies to servers withoutmodification by the client; clients following links presented to them bythe server; clients not modifying the path portions of Uniform ResourceIdentifiers (“URIs”) before requesting them; clients not modifyingqueries embedded in the application data; and clients only supplyingform data which conforms to the application's expectations orconstraints. Constraints that may be used include the length of thedata, type of the data, conformance to types of variables or expectedvalues.

[0012] In an embodiment, a transmission of the application data from anapplication server is intercepted, proxied, processed or filtered toidentify one or more URLs embedded within the transmissions. A predictedform of a client request containing the one or more URLs is generated,indicating how the URL is expected to be requested in the future, andsecurity metadata containing constraints on the manner in which theclient requests the one or more URLs is generated. The application datais combined with the security metadata and transmitted to the client.When the client returns the URI and the security metadata via a request,the URI is validated against the security metadata to ensure that theURI fits within the constraints by which the client may request theURLs.

[0013] In an embodiment, a cryptographic signature is applied over thepredicted form of the client request containing the one or more URLspreviously transmitted by the application server. The client may returnthe transmission including the security metadata and the cryptographicsignature. The cryptographic signature may be verified to ensure thatneither the metadata nor the URI have been altered.

[0014] In an embodiment, a system is generated in which a subsystemreceives resource requests from a client to an application server, and astate signing subsystem signs responses to the resource requestsdelivered to a client from the application server to indicateauthenticity. Each of the system and the subsystem may include one ormore of hardware and software.

[0015] Enabling/disabling state signing for various data items may becontrolled through policies tied to URL prefixes. In an embodiment,individual signatures are accompanied by a control word, embedded intothe client side state, and covered by the signature. In an embodiment,the control word includes one or more flags and values which control howthe signature is verified when the data item is returned.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are incorporated in and form apart of the specification, illustrate embodiments of the presentinvention and, together with the description serve to explain theprinciples of the invention.

[0017]FIGS. 1A and 1B illustrate exemplary direct and indirectclient-server requests for application data, respectively, according toembodiments;

[0018]FIG. 2 illustrates an exemplary client-server model using a statesigner for application data signing and verification according to anembodiment;

[0019]FIGS. 3A and 3B illustrate exemplary signed URLs and cookies,respectively, according to embodiments;

[0020]FIG. 4 illustrates an exemplary table of signature metadataaccording to an embodiment;

[0021]FIG. 5 illustrates an example of cookie signing for a set cookieoperation according to an embodiment;

[0022]FIG. 6 illustrates an example of cookie signing according to anembodiment.

DETAILED DESCRIPTION

[0023] In describing the embodiments of the invention illustrated in thedrawings, specific terminology will be used for the sake of clarity.However, the invention is not intended to be limited to the specificterms so selected, and it is to be understood that each specific termincludes all technical equivalents which operate in a similar manner toaccomplish a similar purpose.

[0024] Computer program instructions for implementing a softwareembodiment of the present invention may be stored in a computer programmemory or on a computer readable carrier such as a disk, memory stick,portable memory device, communications signal or carrier wave. The stepsto complete the methods described herein may be carried out in anycomputer programming language including object oriented programsincluding but not limited to Java, C++, Visual Basic, Perl, PHP, andprocedural programming languages such as C and Fortran. Other types ofprogramming languages may be utilized, and the invention is not limitedto any particular programming language, procedural, object oriented orotherwise.

[0025] Computing platforms for implementing the system include but arenot limited to microprocessors and associated peripherals such asexternal Random Access Memory (RAM), Read Only Memory (ROM) and storagedevices including but not limited to magnetic drives, optical andmagneto-optical drives, removable storage devices including CD-ROMs,removable magnetic cards, or other types of fixed or removable storagedevices. Network interfaces are also included in the computing platformin the form of Ethernet cards, adaptors or other components that allowthe transmission and reception of data to and from other computers.Multiprocessor systems and network processors, used individually orcoupled together, may be utilized. A computing platform may beconstructed from elementary components including a microprocessor andassociated peripherals, or may be a pre-assembled computer or computingworkstation. The system may also be implemented on custom hardwareincluding Application Specific Integrated Circuits (ASICs) or FieldProgrammable Gate Arrays (FPGAs). In addition, the system can beembodied in an application server as a web server module, servlets, CGIprograms or scripts, server side includes, or directly into the webserver source code, application source code either dynamically orstatically, or into the operating system itself.

[0026]FIG. 1A illustrates an exemplary configuration for directclient-server requests according to an embodiment. As shown, a client100 may issue a request 102 to a server 110. The server 110 may reply tothe request 102 with application data 104 and a return request 105,where the return request 105 is triggered by the application data 104.The request 102 may be in the form of a URL containing a HTTP addressfor a resource such as a web page, a File Transfer Protocol (FTP)command or other instruction requesting data, code or other digitalinformation from the server 110. The server 110 may subsequently returnapplication data 104 to the client 100. The application data 104 maycontain the requested data, code or other digital information. Theapplication data 104 may alternately include error messages indicatingthat the requested information is not available.

[0027] Referring to FIG. 1B, a firewall/proxy 120 may be used betweenthe client 100 and the server 110. When the firewall/proxy 120 is usedas a firewall, packets that comprise the request 120 may be examined todetermine if they contain requests that could be harmful to the server110. If it is determined that a request 120 is potentially harmful tothe server 110, based on a complex set of rules for inspection of thepackets, the request 102 may not be forwarded to the server 110.

[0028] When the firewall/proxy 120 is used as a proxy, it may interceptall requests 102 made by the client 100 and determine if those requestsare safe for the server 110. If the requests 102 are deemed to be safe,the proxy 120 forwards the request 103 to the server 110 on behalf ofthe client 100. In both cases, if the request 103 is approved, theapplication data 104 is returned from the server 110 to the client 100.Subsequent return requests 105 may be subject to the same inspectionprocess to determine if they are safe for the server 110. In all cases,acceptable request are forwarded to the server 110 without modification.In an embodiment, the firewall/proxy 120 also subjects application data104 to tests that determine if the application data 104 carries signs ofa successful attack. The application data 104 may be dropped if the testindicate that an attack has been carried out.

[0029] Referring to FIG. 2, the present method, system and software mayuse a state signer 200 that is placed between the client 100 and theserver 110 to receive a request 102 and forward the request 102 to theserver 110 as a forwarded request 103. The forwarded request 103 may bea proxy request, with either the state signer 200 or another deviceacting as the proxy. Upon receiving the forwarded request 103, theserver 110 may fulfill the request by sending application data 104 tothe state signer 200. The state signer 200 may perform a signingoperation that results in signed application data 202 being sent to theclient 100. The client 100 may make a signed return request 204 based onthe request 102. The state signer 200 may examine the signed returnrequest 204 to determine if the data received by the client 100 has beentampered with. If the data has not been tampered with, a verified returnrequest 206 may be made to the server 110. If the state signer 200 doesnot verify the signed return request 204, the state signer 200 may,based on its configuration, ignore the request completely, resulting ina dropped request 215, or reply to client 100 with a denied request 217bearing an error code. In an embodiment, all requests subsequent to thereceipt of signed application data 202 are signed return requests, suchas signed return request 204. In an alternate embodiment, the statesigner 200 is configured to verify only certain requests and to signonly certain application data 104. This discriminatory verification andsigning may be accomplished through the use of policies installed intothe state signer 200 that select which pieces of application data 104are signed in the signed application data 202. These policies may betriggered by or based on URI prefixes associated with each applicationelement, user IDs or other policy predicates. The policies may also beused to determine which requests are in the signed return request 204 asopposed to the unsigned return request form of return request 105.

[0030]FIG. 3A illustrates a signed URL containing a URL data item 300, aControl Word (CW) 330, an Extended Control Word 1 (ECW1) 320, anExtended Control Word 2 (ECW2) 310, and a signature 340. The URL dataitem 300 may contain a request for resources. The Control Word 330, theExtended Control Word 1 320, and the Extended Control Word 2 310 maycontain metadata indicating one or more aspects of how the URL data item300 is used. In an embodiment, the URL data item 300 is signedseparately from the metadata. In an alternate embodiment, a query fieldmay indicate a portion of the URI corresponding to user-supplied data.The signature 340 may cover this portion of the request if the query waspresent in the application data 204 when signing took place. Conversely,if the query represents user-supplied data, the signature 340 does notcover the text of the query. In this instance, ECW1 320, for example,may contain a Form Verification Block (FVB) that imposes constraints.The FVB may be covered by the signature 340, may constrain the data thatappears in the query and may apply constraints on the data that appearsin the body of the request. CW 330 may include information allowing thestate signer 200 to determine which portions of the request are coveredby the signature 340 (e.g. query signed v. query not signed) andindicating the presence or absence of FVB information. Similarly, therequest 300 may also include a fragment identifier that refers to asubsection of the requested resource. Since the fragment is neverreturned in a subsequent client request, the signature 340 does notcover the text of the fragment identifier.

[0031] Referring to FIG. 3B, a signed cookie is illustrated in which acookie data item 350 is combined with metadata, comprising CW 330 andECW1 320, and the signature 340 to produce a cookie item containingadditional information such that the state signer 200 can verify itsauthenticity and safety.

[0032]FIGS. 5 and 6 illustrate cookie-signing examples for a set cookieoperation and a return cookie operation, respectively. The upper portionof FIG. 5 illustrates the set cookie header before signing. The lowerportion of FIG. 5 represents the set cookie header after signing. In anembodiment, the data items of“PART NUMBER,” “BASS_CLARINET,”“ITEM_PRICE” and “$237.14” are signed. In an alternate embodiment, thecookie attributes (e.g. path and secure) may be signed. Referring toFIG. 6, the data items of “CUSTOMER,” “WILE E COYOTE,” “PART_NUMBER,”“ROCKET LAUNCHER 001,” “SHIPPING” AND “FEDEX” in the upper portion ofFIG. 6 are signed.

[0033] Signatures are generated using keys and the text (data fields,metadata fields, or combinations thereof) to be signed. In anembodiment, the signature of a data item is generated using threeinputs: UID, text, and key:

[0034] a uid: the numeric user ID of the requesting user, expressed asan ASCII-encoded hex value, true integer or other numericalrepresentation.

[0035] text: holds all text of the object to be protected, and in thisembodiment includes signature metadata. For cookies, the text is thesingle Name/Value (NV) pair appearing after a “Set-Cookie:” or“Set-Cookie2:” literal, excluding reducible white space. In thisembodiment, and as illustrated in FIGS. 5 and 6, each NV pair is signedseparately and the header arguments are not signed. For URLs, the textmay include the fully resolved URL including the protocol, host and fullpath.

[0036] key: a system-wide randomly generated character string, 20 bytesin length, zero-padded out to 64 bytes.

[0037] In an embodiment, a system-wide state signing key, the User IID(UID) associated with the request and the text of the data item (cookieor URL) modified with metadata are concatenated and used as input to acryptographic signing algorithm. The resulting value from this signingoperation may be appended to another permutation of the system-widestate signing key and used as input to the signing algorithm again. Inthis embodiment, the signature incorporates the identity of the user forwhom it was generated in order to prevent the theft of signed elementsfrom caches and cookie files as well as snooping (including proxies suchas local proxies, reverse proxies, distributed proxies, corporateproxies, or other proxies).

[0038] In an embodiment, signing a data item means performing thefollowing transformation over its text:$\left. {{sign}\left( {\underset{\_}{text},\underset{\_}{uid},\underset{\_}{key}} \right)}\Rightarrow{{SHA1\_ t}\left( {{{key} \oplus {opad}} + {{SHA1\_ b}\left( {{{key} \oplus {ipad}} + {uid} + {text}} \right)}} \right.} \right.$

[0039] where the following definitions hold:

[0040] The plus operator (‘+’) is meant to indicate stringconcatenation;

[0041] The O-plus operator (‘⊕’) is meant to indicate exclusive bitwiseOR (XOR) operation;

[0042] SHA1_t(text) returns the SHA1 digest of its argument, text, as ahex string (40 characters);

[0043] SHA1_b(text) returns the SHA1 digest of its argument, text, as a20 byte number;

[0044] ipad=the byte 0×36 repeated 64 times;

[0045] opad=the byte 0×5C repeated 64 times; and

[0046] key=the encryption key used to generate the secure signature.

[0047] This function returns the signature to be appended to the statedata.

[0048] In addition to the signature itself, a control word may beincorporated into the item's text before signing it. The control wordcarries information used by the state signer 200 when later verifyingthe signature. In an embodiment, the control word is expressed as anASCII-encoded 3-byte hex value (6 characters).

[0049]FIG. 4 illustrates a table for Control Word 330 content used inone embodiment. CW 330 includes metadata that may indicate the intent ofthe request, as well as information regarding the signature, how thatsignature was obtained and a marker facilitating rapid discrimination ofsigned from unsigned requests.

[0050] In an embodiment, CW 330 has the following grammar:

[0051] CTRLWD=“F81” KEY QUERY SECURE

[0052] KEY=“0” for key 0 or “1” for key 1

[0053] QUERY=“8” for ignore query or “C” for sign query

[0054] SECURE=“0” for http backend 0 or “8” for https backend

[0055] In the abovementioned embodiment, eight legal hexadecimal valuesof CW 330 may be used: 0xF81080, 0xF810C0, 0xF81180, 0xF811C0, 0xF81088,0xF810C8, 0xF81188 and 0xF811C8. In an embodiment, CW 330 appears in apredictable location within any signed text, thus the presence of thetext “F81” may be used to distinguish signed content from unsignedcontent. In this embodiment, extra “marker bits” are included in thecontrol word.

[0056] ECW1 320 and ECW2 310 may be used for FVBs and Signature ExpiryBlocks (SEBs), respectively. SEBs may contain an ASCII-encoded date(e.g. ASN.1) beyond which the signature is considered invalid. Each maybe used for other purposes as well and may act as extensions to CW 330.

[0057] It is preferable, for security reasons, to update or regeneratethe key used for encryption periodically to protect against thepossibility of undetected key compromise. In an embodiment, asystem-wide key is used rather than per connection, per-application, orper-user keys. In this embodiment, two keys are active in the system atany given time to allow for periodic rotation of the keys. A simpleindex may be used to track which key is active. In alternateembodiments, a larger number of keys can be used, or the keys can bevaried for each connection, application or user. As will be understoodby one skilled in the art, a variety of security techniques may beapplied for key generation, and public key and/or private key systemsmay be used.

[0058] Changing or rotating keys may result in a broken client-sidestate resulting in unusable bookmarks, cookies and/or cached web pages.In an embodiment, the key regeneration interval is set to one month toallow for a maximum two-week window of usability for the client-sidestate. In addition, the system administrator may cause the state signer200 to return a “301 Permanent Redirect” message for requests using akey that is valid but not current. This redirect may include a URIsigned using the current key. This process may permit bookmarks andcache entries to be updated in many types of Internet browsers includingINTERNET EXPLORER® browsers produced by Microsoft Corporation. In thisembodiment, bookmarks remain current as long as they are requested atleast once every key refresh period. In an alternate embodiment, linkverifier software is used to verify the link and refresh broken linkswith data signed by the current key.

[0059] In an embodiment, keys are 20 bytes long and arecryptographically random. In this embodiment, the keys are generated bya random number generator, such as the random number generator producedby Cavium Networks. Other embodiments with longer or shorter keys arepossible, and as previously mentioned, a number of key generationtechniques may be utilized.

[0060] In an embodiment, cookie signing can be enabled or disabled. Inthis embodiment, cookie signing may be controlled on the basis of theURI prefix of the requested URI, as well as the URI prefix of thecookie's PATH attribute. In this embodiment, if cookie signing isdisabled on any URI prefix, the setting is not re-enabled on any URLdescendant of that prefix.

[0061] A cookie may not always bear a PATH attribute. For a cookiewithout a PATH attribute, the standard protocol may be to default to therequest-host for the domain and the path of the request URL thatgenerated the set-cookie response, up to, but not including, theright-most “/.” Preferably, all cookie signing operations occur only onthe re-written cookie attributes. In this embodiment, cookie signingtakes place after the rewrite on the request headers, but before therewrite on the response headers. When an incoming Cookie:request headeror Set-Cookie:response header is received, a prefix table lookup may beperformed over the text of its PATH attribute. If cookie signing isenabled, for that PATH, a valid signature must appear on that cookie. Ifnot, the cookie may be passed through unmodified. A management interfacemay be provided to ensure that if cookie signing is disabled on anyparticular prefix, other policies bearing that prefix “inherit” thatstate.

[0062] With respect to cookie requests, the process may be initiated byconsulting a policy database to determine the state of the cookiesigning feature (enabled/disabled) for both signature checking and thesubsequent signature generation. In an embodiment, the authenticateduser ID of the requestor is also examined.

[0063] For cookie bearing requests that need to be verified, a signaturemay be generated over the user ID and the name value text (plus controlword and metadata). The generated signature may be compared to thesignature embedded in the returned cookie to determine if the generatedsignature is indeed verified. If the generated signature is verified,the cookie passes verification. If it is not verified, the cookie, alongwith its associated attributes, is deleted from the output stream.

[0064] For cookie bearing replies, the state of the cookie signingfeature associated with the original URI request may be recalled.

[0065] In a next step for cookie replies, a scan may be performed at theapplication layer to detect cookie headers and to return the appropriatefields including the cookie name, value, domain, and path. This step mayalso be performed on cookie requests.

[0066] For identified cookies, a control word may be added. The cookiemay then be signed and appropriately inserted into the output stream.

[0067] For URL signing, relative URLs may first be resolved to permitsigning. Exemplary URLs that need to be resolved may includenetwork-path references, absolute-path references and relative-pathreferences. Although fully resolved URLs are used in signaturegeneration, the output stream may not need to reference the fullyresolved URL.

[0068] In both cookie and URI signing, the state signer 200 may removethe signature, CW 330 and associated metadata from the requested URIand/or cookie before forwarding it to the application server 110.

[0069] Although the invention has been described with reference to thepreferred embodiments, it will be apparent to one skilled in the artthat variations and modifications are contemplated within the spirit andscope of the invention. The drawings and description of the preferredembodiments are made by way of example rather than to limit the scope ofthe invention, and it is intended to cover within the spirit and scopeof the invention all such changes and modifications.

What is claimed is:
 1. A method for monitoring transmissions between anetwork application server and a client, the method comprising:incorporating security metadata in a server transmission from a networkapplication server to a client, wherein the security metadata includes adescription of the intended network application semantics; receiving aclient transmission from the client, wherein the client transmissionincludes returned metadata; and determining, using the returnedmetadata, whether the client transmission conforms to the intendednetwork application semantics.
 2. The method of claim 1, wherein thesecurity metadata is transmitted with application data.
 3. The method ofclaim 1, wherein the security metadata is transmitted separate fromapplication data.
 4. The method of claim 1, wherein the securitymetadata further comprises authorization information for clienttransmissions, wherein the authorization information indicates whichclient transmissions are authorized.
 5. A method applied between anetwork application server and a client to ensure data security:intercepting a transmission of application data from a networkapplication server to a client; identifying one or more Uniform ResourceLocators (URLs) embedded in the transmission; generating securitymetadata containing constraints on the manner in which the clientrequests the one or more URLs; and transmitting the transmission ofapplication data and the security metadata to the client.
 6. The methodof claim 5, further comprising: receiving a client transmission from theclient, wherein the client transmission includes a URL request and thesecurity metadata; and validating the URL request against the securitymetadata to ensure that the URL request fits within the constraints onthe manner in which the client requests the one or more URLs.
 7. Themethod of claim 5, further comprising generating a cryptographicsignature over the predicted form of the client request containing theone or more URLs previously transmitted by the application server, andwherein transmitting further comprises transmitting the cryptographicsignature to the client.
 8. The method of claim 7, further comprising:receiving a transmission from the client, wherein the transmission fromthe client includes a URL request and the security metadata; validatingthe URL request against the security metadata to ensure that the URLrequest fits within the constraints on the manner in which the clientrequests the one or more URLs; and verifying the cryptographicsignature.
 9. An apparatus for monitoring transmissions between anetwork application server and a client, the apparatus comprising: atransmitter for incorporating security metadata in one or more servertransmissions from a network application server to a client, wherein thesecurity metadata includes a description of the intended networkapplication semantics; a receiver for receiving one or more clienttransmissions from the client, wherein the one or more clienttransmissions include returned metadata; and an analyzer fordetermining, using the returned metadata, whether the one or more clienttransmissions conform to the intended network application semantics. 10.The apparatus of claim 9, wherein the security metadata is transmittedwith the application data.
 11. The apparatus of claim 9, wherein thesecurity metadata is transmitted separate from the application data. 12.The apparatus of claim 9, wherein the security metadata furthercomprises authorization information for client transmissions, whereinthe authorization information indicates which client transmissions areauthorized.
 13. An apparatus for insuring data security, comprising: areceiver for intercepting a transmission of application data from anetwork application server to a client; a parser for identifying one ormore URLs embedded in the transmission; a metadata generator forgenerating security metadata containing constraints on the manner inwhich the client requests the one or more URLs; and a transmitter fortransmitting the transmission of application data and the securitymetadata to the client.
 14. The apparatus of claim 13, furthercomprising: a second receiver for receiving a client transmission fromthe client, wherein the client transmission includes a URL request andthe security metadata; and a validator for validating the URL requestagainst the security metadata to ensure that the URL request fits withinthe constraints on the manner in which the client requests the one ormore URLs.
 15. The apparatus of claim 13, further comprising a generatorfor generating a cryptographic signature over the predicted form of theclient request containing the one or more URLs previously transmitted bythe application server, and wherein the transmitter further transmitsthe cryptographic signature to the client.
 16. The method of claim 15,further comprising: a second receiver for receiving a transmission fromthe client, wherein the transmission from the client includes a URLrequest and the security metadata; a validator for validating the URLrequest against the security metadata to ensure that the URL requestfits within the constraints on the manner in which the client requeststhe one or more URLs; and a verifier for verifying the cryptographicsignature.
 17. A system for performing state signing of networkresources, comprising: a first subsystem for receiving one or moreresource requests from a client to an application server; and a statesigning subsystem for signing responses to resource requests deliveredto a client from the application server, wherein the resource requestsare signed to indicate authenticity.
 18. The system of claim 17, whereinthe state signing subsystem includes a cryptographic signature for thegeneration of a cryptographic signature over at least a portion of theresponse to the resource request.
 19. The system of claim 18, whereinthe state signing subsystem further includes a verification subsystemfor the determination as to whether a resource request has been altered.20. A computer program embodied on a computer-readable medium forsigning the state of application data transmitted over a network, thecomputer program comprising: a source code segment for intercepting atransmission of application data from an application server to a client;a source code segment for identifying one or more URLs embedded in thetransmission; a source code segment for generating security metadatacontaining constraints on the manner in which the client requests theone or more URLs; a source code segment for transmitting thetransmission of application data and the security metadata to theclient.
 21. The computer program of claim 20, further comprising: asource code segment for receiving a client transmission from the client,wherein the client transmission includes a URL request and the securitymetadata; and a source code segment for validating the URL requestagainst the security metadata to ensure that the URL request fits withinthe constraints on the manner in which the client requests the one ormore URLs.
 22. The computer program of claim 20, further comprising asource code segment for generating a cryptographic signature over thepredicted form of the client request containing the one or more URLspreviously transmitted by the application server, and wherein the sourcecode segment for transmitting further transmits the cryptographicsignature to the client.
 23. The computer program of claim 22, furthercomprising: a source code segment for receiving a client transmissionfrom the client, wherein the client transmission includes a URL requestand the security metadata; a source code segment for validating the URLrequest against the security metadata to ensure that the URL requestfits within the constraints on the manner in which the client requeststhe one or more URLs; and a source code segment for verifying thecryptographic signature.